1. Technical Field
The present invention relates to communication networks generally. More specifically, the present invention relates to a method and system for resolving Domain Name System (DNS) queries in a multiprotocol communications network.
2. Description of the Related Art
In many conventional communications networks, a domain name system (DNS) is used to translate between textual domain name strings often utilized as user labels for network elements (hosts, routers, etc.) and numerical addresses utilized to route data between source and destination nodes within communications network domains. A DNS system typically includes one or more DNS clients (e.g., an Internet browser client application) and one or more DNS servers (e.g., resolvers, name servers, etc.) arranged hierarchically within network elements of a communications network.
In many conventional communications networks, a single protocol, (e.g., IPv4) is implemented at the network layer level. As other network layer protocols, (e.g., IPv6) have been introduced, multiprotocol communications networks including network elements which implement any of two or more network-layer protocols exclusively and/or multiple protocols simultaneously have become more prevalent.
FIG. 1 is a high-level process flow diagram of a domain name system (DNS) query resolution process according to the prior art. In the illustrated process, a source network element first generates a domain name system (DNS) query for a destination network element's domain name (process block 102). As will be described in greater detail with respect to FIG. 2, a standard DNS query includes a destination or “target” domain name to be resolved, a query type specifying the type of resource record requested in the query, and query class. A determination is then made whether the query type of the generated query specifies a resource record associated with an IPv4 address (e.g., an A record) or an IPv6 address (e.g., a AAAA or A6 record) (process block 104).
Following a determination that an IPv4-type resource record type has been requested, the source network element transmits the generated DNS query to a DNS server utilizing an IPv4 transport (process block 106A). Each DNS client is capable of contacting at least one DNS server (e.g., the name server for the DNS client's domain). DNS servers use a well-known protocol port for all communication, so clients may consequently communicate with a server once the address of the machine in which the name server executes is known. In some systems the address of the machine that supplies domain name service is bound into application programs at compile time while in others the address is configured into the operating system at startup. In still others systems, an administrator places the address of a name server in a file on secondary storage.
The DNS server receives the source network element-transmitted DNS query (process block 108A) and attempts to resolve the query. A determination is then made whether or not the queried DNS server includes an IPv4 address resource record (A record) corresponding to the query-specified domain name (process block 110A). If so, the DNS server provides the IPv4 address to the source network element (process block 112A). The source network element then receives the IPv4 address (process block 114A) and utilizes it to communicate with the destination network element (process block 116A). According to the prior art, the transmission of IPv4 addresses from the DNS server to the source network element (process block 112A) and communication between the source and destination network elements (process block 116A) is performed using the same transport type as was utilized to transmit the DNS query to the DNS server (process block 106A) (i.e., IPv4).
If a determination is made that the queried DNS server does not include an IPv4 address resource record (an A record) corresponding to the query-specified domain name, the DNS server indicates to the source network element that the queried name is unknown utilizing an IPv4 transport (process block 118A) and the process of the illustrated embodiment is terminated. In an alternative prior art embodiment not illustrated by FIG. 1, if a determination is made that the IP address resource record cannot be provided the DNS server determines whether the DNS query is recursive or iterative. For a recursive DNS query, the DNS server recursively queries other DNS servers to resolve the query and then provides the resolved IPv4 address to the source network element. For an iterative DNS query, the DNS server generates a reply utilizing an IPv4 transport which specifies another DNS server that the source network element should contact.
Following a determination that an IPv6-type resource record has been requested, a procedure (process blocks 106B-118B) paralleling that described with respect to process blocks 106A-118A is performed. As with the previously described procedure, the transmission of IPv6 addresses from the DNS server to the source network element (process block 112B) and communication between the source and destination network elements (process block 116B) is performed using the same transport type, (IPv6 here), as that utilized to transmit the DNS query to the DNS server (process block 106B).
As will be apparent from the preceding description, conventional methods of resolving DNS queries within multiprotocol (e.g., mixed IPv4 and IPv6) communications networks suffer from several drawbacks. One such drawback, illustrated by FIG. 1, is that such conventional methods require that the same protocol (i.e., either IPv4 or IPv6) is utilized to perform a DNS query as will be utilized to communicate with the destination network element which is the subject of the DNS query. Consequently, resource records (e.g., A records for IPv4 addresses and AAAA or A6 records for IPv6 addresses) associated with a given protocol are prevented from being usefully stored within and accessed from a DNS server which is not compatible with that particular protocol, making a transition from IPv4 to IPv6 more difficult and costly.
Another significant drawback associated with conventional DNS query resolution methods is that in using such methods, it is typically presumed that no DNS server is any more likely or capable of resolving a DNS query than any other DNS server. Accordingly, in generating iterative DNS queries, a DNS client software application (or DNS server attempting to resolve a recursive DNS client query) will typically query each DNS server it has access to in turn in order to resolve a DNS query. Although the performance penalty associated with this technique is relatively small for the majority of network elements (e.g., hosts) which have access to only one primary and possibly one secondary DNS server, it may be substantially larger for other network elements (e.g., network elements within a corporate communications network, routers, etc.) having access to a greater number of DNS servers.